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Abstract 

In object systems, classes take the role of modules, and interfaces 
consist of methods. Because methods are encapsulated in objects, in- 
terfaces in object systems do not allow abstracting over where methods 
are implemented. This implies that any change to the implementation 
structure may cause a rippling effect. Sometimes this unduly restricts 
the scope of software evolution, in particular for methods with mul- 
tiple parameters where there is no clear owner. We propose a simple 
scheme where symmetric methods may be defined in the classes of 
any of their parameters. This allows client code to be oblivious of 
what class contains a method implementation, and therefore immune 
against it changing. When combined with multiple dynamic dispatch, 
this scheme allows for modular extensibility where a method defined 
in one class is overridden by a method defined in a class that is not its 
subtype. In this paper, we illustrate the scheme by extending a core 
calculus of class-based languages with these symmetric encapsulated 
multi-methods, and prove the result sound. 

1 Introduction 

Evolution of large software can only stay manageable when the rippling 
effect of change is to some degree constrained. One way of achieving this is 
to program in terms of modules that communicate through interfaces [1] . A 
change to an interface may still cause a rippling effect, but implementation 
details that are abstracted over (that are hidden behind the interface) may 
change without such a global impact. 

In object technology, classes act as modules, and interfaces are made of 
methods. However, because methods are encapsulated in objects, interfaces 
in object systems do not allow abstraction over where a particular method 
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is implemented. This implies that every time a change is made to the im- 
plementation structure of an application, i.e. anytime a method is moved, a 
rippling effect may occur. 

Some movements of methods, however, do not fundamentally alter the 
implementation structure, and it may be desirable to make such changes 
without incurring a rippling effect. In particular, we are thinking of sce- 
narios where methods are moved from the class of its receiving parameter 
to the class of any of its other parameters. As any practitioner can vouch, 
the choice of which class to assign responsibility for a method (especially 
one with multiple object parameters) may sometimes lie in the eye of the 
beholder. Hence it may be subject to change, either because of evolving 
insight into the design trade-offs, or simply for pragmatic reasons. 

A common way of side-stepping rippling change when a method imple- 
mentation needs to move from one class to another is to write proxy-code 
to forward the method invocation to its new destination. Presence of proxy 
code may act as evidence that the flexibility of moving methods is desirable. 
Such proxy code frequently occurs in recently emerging application fields 
such as Ubiquitous Computing and Service-Oriented Computing. In fact, it 
was our experience in designing a programming language for these fields [?] 
that prompted our interest in this kind of malleability. Hence, one may 
assume that malleability of this kind will gain in importance together with 
further development of these application fields. 

As an example, consider a method that registers a transaction between 
a shop, an item and a customer. This method may be defined in the class 
that models shops. A client that invokes this method would therefore write 
something along the lines 

shop .transact ion (item, customer) 

If it were later to be decided that this is not the optimal place for the method 
implementation to reside, and it was moved to the class representing items, 
then this client would break. Adding a proxy-method to the shop class, 
although common, is not entirely desirable. The main issue lies with having 
to manually add and maintain the code, but more subtly, proxy code also 
essentially takes the form of double dispatch invocation and therefore has 
slightly different dispatch semantics from the original. 

To tackle this issue, we propose a scheme where methods are written in 
symmetric form and may be defined in the class of any of its parameters. 
With methods in symmetric form, we mean methods that list their receiving 
parameter explicitly, thereby treating all their parameters uniformly. De- 
spite not giving any parameter special treatment, symmetric methods are 
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encapsulated in the class in which they are defined. In other words, they 
have unrestricted access to the bowels of that class, and depend on the access 
model of the language for access to the other parameters. 

Under such a scheme, the above transaction method may be defined in 
either the shop, item, or customer class. For example, it may be defined in 
the item class as below, while not breaking a client that assumes the method 
being defined in the shop class. 

class Item { 

void transaction (Shop s, Item i, Customer c) { 
... > 

> 

A main feature of object-orientation is its modular extensibility: method 
behaviour can be extended for derived classes (subtypes) without changing 
the original class. To achieve this, a subclass may define a method with 
the sam^ signature that overloads the original method name with new 
behaviour. The discretely specified method bodies together make up the 
method and are called its branches. What method body is executed is de- 
cided at run-time based on the type of the receiving parameteiH. 

We would like to generalize this ability to discretely specify method be- 
haviour to our setting with encapsulated symmetric methods. For example, 
consider a charity shop class that is a subclass of the shop class. We would 
like to be able to define an extension of the transaction method that deals 
specifically with charity shops in the charity shop class, and have it invoked 
whenever the argument to the method is a charity shop. 

class CharityShop extends Shop { 

void transaction (CharityShop cs, Item i, Customer c){ 
... > 

} 

To achieve this -while avoiding ad-hoc invocation semantics for different 
method call sites- we need to resort to multiple dynamic dispatch, also known 
as multi-methods. With multi-methods methods may be discretely specified, 
and branch selection is based on the dynamic type of all parameters. It is this 
characteristic that makes that branches may specialize any of the parameter 
types, and still be taken into account during selection. Note how the above 

'^Or, depending on the flexibility, a conforming signature. 

In addition, there may be a separate mechanism with which methods my be statically 
overloaded. 
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method specializes a method that is not defined in its superclass, but in the 
unrelated item class. 

This brings us to a model with encapsulated symmetric multi- methods, 
in which the location of method implementations is partially abstracted over, 
and methods may be discretely specified along the hierarchies of the different 
argument classes. Clients, while still receiving the same level of feedback as 
before from static typing, can write code that is to a degree independent of 
where methods are implemented, and therefore may remain unchanged when 
the implementations are adapted or extended. The net effect of employing 
this scheme over standard object technology is that there is an increase in 
malleability of software, with the well-known software engineering benefits 
as a result. 

In the next sections, we incorporate the ideas above into a core object- 
oriented calculus (Featherweight Java). We start by discussing the merits 
of doing so, and then present the adapted formal semantics (Sect. 12. 1112. 4p . 
including new notions of method lookup and selection (Sect. 12. 3p . and con- 
straints on branches of overloaded methods (Sect. 12. 4p . Soundness of the 
extension is tackled in Sect. 12.51 We discuss some observations about dis- 
patching strategies in Sect. ?? Related work follows in Sect. [3l and finally 
we present our conclusions in Sect. HI The appendices contain an overview 
of the different formal definitions. 

2 Symmetric Featherweight Multi-Java 

We illustrate our ideas by extending Featherweight Java (FJ) [2] with sym- 
metric encapsulated multi-methods, the result we call Symmetric Feath- 
erweight Multi- Java (SFMJ). In particular, (z) we change the syntax for 
method definition and invocation to make all parameters explicit, {ii) we 
allow methods to be defined in the class of any of its parameters, and {iii) 
we introduce multiple dispatch. 

We use FJ as a paradigmatic core calculus for mainstream class-based 
object-oriented languages. Our results are more generally applicable than 
to Java only. However, FJ proved to be useful vehicle for our explorations, 
because despite its simplicity it models method invocation in enough detail 
that we can adapt it for our purposes with little increase in complexity. In 
fact, the changes to the calculus are localized to method definition, invoca- 
tion, and selection. As a result we may even establish soundness of SFMJ 
by a proof that is a limited extension to the one of FJ. 

An in-depth discussion of FJ is beyond the merit of this article. We 
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refer the reader to [2] , from which we also borrow the syntactic conventions 
without further comment. The structure of our exposition also mirrors the 
original one. An overview of the entire specification of SFMJ can be found 
in Fig. [2] and Fig. HI To facilitate comparison with FJ, we also list the parts 
of the specification that have been altered in Fig. O 

2.1 Syntax 

Like FJ, an SFMJ program is a tuple (CT, e) of a class table and an ex- 
pression. A class table is a mapping from class names to class declarations. 
The class table is assumed to be fixed, and implicitly accessible to all the 
semantic rules. Class declarations list the ancestor of the class (single inheri- 
tance), and in the body the fields, constructor and methods. There can only 
be a single constructor, and it takes a stylized fornH. Methods may have any 
number of parameters (note the bar notation to indicate sequences), all with 
explicitly declared type, and a single return type. Method body consists of 
a single expression, which denotes the value returned on method invocation. 
The expressions consist of variables (which may be used to denote fields 
or arguments), field access, method invocation, object creation and casting. 
There is only one kind of values (expressions in normal form): objects, which 
are object creation expressions with their arguments fully evaluated. Note 
how objects carry their type, making it available at run-time. The syntax 
of SFMJ can be found in Fig. [1] below. 



L 


::= class C extends C {Cf; KM} 


class declarations 


K 


::= C{C f) {super(/); this./ = /; } 


constructor declarations 


M 


::= C m{C x){return e; } 


method declarations 


e 


::= X 


variables 




e.f 


field access 




m{e) 


method invocation 




new C(e) 


object creation 




(C)e 


cast 


V 


::= new C{v) 


objects 



Figure 1: Syntax of SFMJ 
^See the FJ exposition for more details 
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Note that the sole difference in syntax between FJ and SFMJ hes in 
method invocation: the original asymmetric syntax t.mit) has been changed 
to a function-like m{i) that treats all parameters uniformly. Syntax for 
method definition, and the fact that methods may now be defined in more 
places can already be accommodated by existing syntax. 

2.2 Reduction 

The operational semantics of SFMJ is specified as a rewriting semantics. 
Reduction reduces expressions to values by successive applications of reduc- 
tion rules. There is just one kind of values (object), as primitive values are 
not modelled. The full specification of the reduction relation can be found 
in Fig. [21 Only reduction of method invocation expressions are of interest 
here. The uniform treatment of parameters yields a single congruence rule 
RC-Invk (compare with RC-Invk-Recv and RC-Invk-Arg in Fig. [5]). 
The computation rule for method invocation expressions states simply that 
for fully evaluated method argument^, the expression reduces to the substi- 
tution of these arguments into the body of the method retrieved by method 
lookup. 

Method lookup is specified in terms the composition of a lookup function 
that locates potentially applicable methods, and a selection function that 
chooses one of these. To support multiple dispatch, the lookup function is 
dependent on the (run- time) types of the actu;i parameter^. Definitions of 
these functions can be found in Sect. 12.31 below. 

Vi = new C(n) 

select{lookup{m, C)) = Bq m{B x) {return eo; } (j^ i ) 

m{v) [v/x]eQ 

Note how the rule retains the basic structure of the original. In fact, with 
appropriate definitions for lookup and select, we may achieve the original 
semantics. Such a definition can be found in Fig. [6l 

2.3 Method Lookup and Selection 
Method Lookup 

The method lookup function yields the set of all methods that are applica- 
ble to the arguments provided. Method lookup in SFMJ must consider that 

^Unlike the original, our rule imposes call-by-value evaluation order, although this is 
immaterial for this story. 

^Note how values (new C{v)) inherently carry their run-time type. 
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definition of methods may reside in the classes of any of their arguments. 
Also, because of overloading, a method name alone does not identify appli- 
cable methods. The lookup strategy consists of two parts. The top-level 
predicate lookup takes a method name and a sequence of classes and returns 
the sequence of methods returned from successive applications of a support 
predicate lookupi to each of the classes in the sequence. The lookupi re- 
cursively inspects a class and all its superclasses for methods that satisfy a 
given signature. 

lookup{m, C) = lookupi{m, C,Ci), . . . , lookupi{m, C, C„) 

lookupi{m,C, Object) = • 

CT{C) = class C extends D{...} 
C <: B Bo m{Bx) {return to;} e M 

lookupi{m, C, C) = Bo m{Bx) {return to; }, lookupi{m, C, D) 

CT{C) = class C extends D {. . .} 
C <: B Bo m{Bx) {vetmn to;} M 

lookupi{m,C,C) = lookupi{m,C , D) 
Method Selection 

Method selection chooses from the set of applicable methods the most appro- 
priate one. This is the method with the signature that most closely matches 
the types of the arguments provided. In other words, it is the most specific 
method that is applicable to the given arguments. The predicate is defined 
as follows: 

select{Bo m{B x) {return e; }) = i?o,i 'rn{Bi Xi) {return e^; } 
s.t. Bi <: Bj Mj e [l,n] 

The existence of a single most applicable method does not come for free, 
it must be asserted by adequate typing restriction, as we will discuss in 
Section US 

2.4 Typing 

The bulk of the changes lie in the typing. This is unsurprising, as we al- 
low methods to be defined in the class of any of its parameters, which in- 
duces changes to class and method typing. Additionally, the introduction of 
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multiple dispatch requires the introduction of (global) constraints to avoid 
ambiguity between method branches. 



Expression Typing 

Method invocation expressions are well-typed when the argument expres- 
sions are well-typed, and a method can be found whose whose formal argu- 
ment types are supertypes of the actual argument types. The rule is very 
similar to the original FJ rule, except for the uniform treatment of param- 
eters and the reliance on the previously defined lookup function. Note that 
the types passed to the lookup are the static (declared) types of the argu- 
ments. The run-time types of the actual arguments will be subtypes of these 
types. Hence, this check establishes that there will be at least one method 
applicable for this method invocation, although more methods may be taken 
into consideration during evaluation. 

rhe:C 

Bq m{B x) {return e; } G lookup{m, C) 

C<:B , ^ 

i-^ r (T-lNVK) 

r h m(e) : C 



2.4.1 Method Typing 

A method definition is well-typed when {i) the method body is well-typed 
assuming the types declared for the formal parameters, (m) the method body 
expression is assigned a type that is a subtype of the declared return type, 
and {Hi) the method is defined in the class of one of the parameters. It differs 
from the typing judgment in FJ, in its uniform treatment of the parameters 
(a pseudo- variable this need not adding to the typing context in which to is 
typed), and in the absence of the invariance restriction on overloading that 
was imposed by the original. Because of support for multiple dispatch we 
have to move the equivalent of such a restriction to the program-level (see 
below). 



X : C h eo : -Eo Eq <: Cq 
3i e [l,n].C = d 

Cq m{C x){return cq; } OK in C 



(T-Meth) 



8 



2.4.2 Program Typing 

In order to make a system with overloaded methods type safe and void 
of ambiguity problems, the set of branch definitions need to be subject to 
some restrictions. It must be noted that in our system, this set may not 
be obtained by looking only at the class in which a method is defined and 
the classes it references. This means that we loose separate compilation 
for SFMJ. To see this, consider the classes A, B, Ai, Bi with Ai <: A and 
Bi <: B. The following method definitions are legal: 

class A { 

void m(A a, B b) {. . .} 

> 

class B { . . . } 

class AI extends A { 

void m(Al a, B b) {. . .} 

> 

class BI extends B { 

void m(A a, BI b) {. . .} 

} 

The branch definitions in Ai and Bi give rise to an ambiguity when m is in- 
voked with instances of Ai and Bi as arguments. However, when inspecting 
the classes referenced by Ai, we do not encounter method branches defined 
in Bi and vice versa. So, we need to look at all classes to make sure we do 
not miss any confiicting branch definitions. 

Note that the introduction of only multi-methods (and not symmet- 
ric methods) into FJ would not suffer from this, as all extensions of m 
would be specified along one hierarchy, and therefore all (non-separate) 
branches would be visible from the leaf classes. The complication -but also 
the fiexibility- of SFMJ derives from the fact that different hierarchies are 
involved, each of which may be independently extended. 

We define the following support function to denote all the branches of an 
overloaded method, based on the observation that two method definitions 
are branches of the same overloaded method if there exist a method that they 
both specialize. Let McT be the set of all methods defined in a program 
{CT,e), and m be a member of that set. Then overloaded(m) denotes the 
subset of McT that contains all the branches of the overloaded method of 
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which m is a member. 

overloaded{Co m{C x){return e; }) = 

{Bq m{B x) {return ei; } | 3Dq m{D {return 62; } € Mct 

s.t.C <: D and B <: D} 

Castagna [3] has estabhshed the minimal constraints branches of an over- 
loaded method must obey. Let O be a set of methods that are branches of an 
overloaded method. For every two methods irii and ruj E O, with respective 
argument types /, J, and return types /q, Jq it must hold that: 

1. K maximal in LB{I,J) =^ a method m with argument type K must 
be in O 

2. I <: J ^ Iq <: Jo 

The second constraint states that the value returned by a method that 
specializes another method should not violate the static return type of the 
method that is being specialized. The first constraint avoids ambiguity of 
method selection by guaranteeing that for any two branches there is always 
a branch that is most specific (be it possibly one of the two). 

We may elaborate a bit on the first constraint in our context to give 
an intuition on how this constraint makes that the lookup and selection 
functions defined in Section 12.31 always yield a single method. Argument 
types are sequences of classes. The maximal lower bound of a sequence is 
the sequence of the maximal lower bounds, if they all exist. Because of single 
inheritance, a maximal lower bound of two classes may only exist if one class 
is a subclass of the other, and it is hence unique (if it exists). This means 
that K is unique, if it exists, and that it is a sequence of classes that are 
mentioned in / and J. The lookup method defined above yields the subset of 
all branches that are applicable to the given arguments. The first constraint 
explicitly states that for any two methods that lookup returns, there exists 
a most specific one in the entire set of branches. Because this most specific 
branch has argument types that are mentioned in the argument types of the 
branches returned by lookup, and because methods are defined in the classes 
of their parameters, we know that lookup must also have returned this most 
specific branch. Hence lookup and select always yield a single method. 

So, to make sure that the set of branches is subject to the above con- 
straints, we introduce the following type judgment for programs. A set of 
branches wellformed if they obey the above constraints. 
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h e : C 

Vm G McT-wellformed{overloaded{m)) 



{CT, e) OK 



(T-Prog) 



2.5 Soundness 



The soundness property that is established for FJ carries over entirely for 
SFMJ: if a term is well typed and it reduces to a normal form then it is 
either a value of a subtype of the original term's type, or an expression that 
gets stuck at a downcast. Formally: 

Theorem 2.1 (SFMJ Type Soundness). . // h e : C and e ^* e' with e' 
a normal form, then e' is either a value v with %\- v : D and D <: C , or an 
expression containing {D)new C{e) where C <: D. 

Having gone through the above exposition, the fact that this property 
carries over must not come as a surprise. We have kept the semantics of most 
constructs constant. The exception being method invocation, for which we 
provide similar guarantees as the original. 

The original proof (cf. [2] Sect. 2.4, and Appendix ^.1) has two parts, 
first establishing Subject Reduction and then Progress. We can carry through 
the soundness proof for SFMJ using the original strategy. In fact, most of 
the proof needs no change. We will follow the original structure of the proof, 
comment on what can stay untouched, and only write out those bits that 
need changing. 

Theorem 2.2. (Subject Reduction). IfT \- e : C and e e' , then F h e' : C" 
for some C' <: C . 

The proof for this theorem relies on three support lemma^. 

Lemma 2.1 (Specificity of Multi- method Dispatch). If select{lookup{m,C)) = 

Bq m{B x) {return cq; }, then for any D <: C select{lookup{m, D)) = Eq m{E x) {return Cq; } 

with E <: B and Eq <: Bq. 

This lemma establishes that method lookup return a more specific method 
when given more specific argument types. 



®In the original proof there are four support lemmas; we will not be needing the last 
one (Lemma A. 1.4 in the paper), as it has to do with the typing of the implicit receiving 
parameter. 
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Proof. We proceed by induction on the number of positions in which the 
input types {C, D) differ. 

subtype relation on input types: for the base case, we prove that the 
lemma holds for identical input types, while for the induction step, we prove 
the lemma holds for an input type that is specific in exactly one position, 
then we 'step up' from one input type, to an input type that is more specific 
in exactly one position. 

• The base case: the input types differ in positions, so D = C. select 
returns the same method, so B = E. 

• The induction step considers the case whereby the input types are 
in k places more specific, assuming the lemma holds branches that 
are in — 1 places more specific. In particular, consider an input 
type D' that is in one place more specific than another input type D: 
D' = Do,...,D'„...,Dn, with D'^ <: A. 

It is trivial to see that when invoked with D', the lookup predicate 
returns a superset of the methods that it returns for D: it returns 
(applicable) branches declared in D'- (and supertypes that are smaller 
than Di), in addition to the ones declared in D, and supertypes. 

From this set, by definition, selects retains the minimal elements. 
Given the well-formedness condition induced by T-Prog, we know 
that for all possible input types there is single most specific method 
branch, let us call it Eq m{E' x) {return Bq';}. We also know that 
because method branches are encapsulated, this most specific method 
branch is in the set returned by lookup. 

Hence we know that E' <: E, and because of induction hypothesis, 
E <: B. 

□ 

Lemma 2.2 (Term Substitution Preserves Typing). IfT,x:B\-e:D, and 
T \- d : A where A <: B, then T h [d/x]e : C for some C <: D. 

The lemma keeps its original form and proof method. The only case that 
changes is T-lNVK, and only because of its reliance on Lemma 1 and the 
symmetric form of methods; the original reasoning for proving the case 
applies entirely. The proof works by induction on the derivation of P, x : 
Bh e: D. 
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Proof. We state only the case for T-Invk: 

Case T-Invk; When the last step in the derivation is T-Invk, we 
have: 



T,x: Bhe:C 
select{lookup{m,C)) = Bq m[B x) {return eo; } 
C <:B 



(T-Invk) 



T,x : A\- m(e) : Bq 

Because of induction hypothesis, we have 
r \- [d/x]e :D D <:C 

Prom Lemma 1, we know that 

select (lookup(m, C)) = Eq m{E x) {return e^; } 

with E <: B and £'0 <: Bq. Using T-Invk on this, we may derive 
r h m{[d/x]e) : Eq 

and hence 

r h [d/x]m{e) : Eq 



□ 



Lemma 2.3 (Weakening). . IfT\- e:C, then T,x : D h e : C. 
• Proof. Original proof holds by relying on the modified lemmas. □ 

We can now give the proof for the Subject Reduction theorem. The 
proof proceeds by induction on the reduction derivation, with case analysis 
on the reduction rule used. The cases for R-Field, R-Cast, RC-Field, 
RC-New-Arg, and RC-Cast remain unchanged. The case for RC-Invk 
is a simple appeal to the induction hypothesis. This leaves only the case for 
R-Invk. 

Proof. 

Case R-Invk: We assume that 
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m(new C{u)) — )• [new C{u)/x]eo 



r h new C{u) : Bq 



(1) 



and set out to prove that 



r h [new C{u)/x]eo : Aq for some Aq <: Bq 



Assumption (1) can only have been derived by apphcation of T-lNVK, 
and T-New on the first premise of that rule. So, we instantly get: 



r h new C{u) : C 
select (lookup (m, C)) = Bq m{B x) {return cq; } 
C <:B 



(2) 



Considering that we assume that methods are well-typed, we know 
from T-Method that 

X : B \- eo : E'owith Eq <: Bq 

Because of the Weakening lemma, we may derive 

T,x : B \- cq : Eq 

Using the Substitution lemma and (2) , we obtain 

r h [new C{u)/x]eo : Aq with Aq <: Eq 

Transitivity of <: gives us the desired result. 



Theorem 2.3. (Progress). Suppose e is a well-typed expression. 

l.Ife includes new C{e).f as a subexpression, then fields (C ) =C f and 
f £ f for some C and f. 

2. Ife includes m[new C(e)) as a subexpression, then select (lookup (m, C)) 

= Bq m{B x) {return cq] } , and #{x) = #(e) for some method Bq m{B x) {return cq; }. 

Only second case is altered. 

Proof. The definition of lookup guarantees that i^{x) = T^(e) for every 

method it returns. The constraints on branch definition guarantee that 

select will return a single method. □ 

The proof of type soundness follows immediately from the Subject Re- 
duction and Progress theorems. 



□ 
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3 Related Work 



Generic methods in languages like CLOS |4j provide similar abstraction 
over application structure as we propose here, and their software engineering 
benefits are well understood in the community. However generic methods are 
globally visible and not encapsulated, and therefore introduce state visibility 
issues (for a discussion see e.g. [5]). 

The combination of encapsulation and the flexibility of changing appli- 
cation structure has been the aim of some research in the Aspect-Oriented 
community. In particular, there has been work on combining different class 
hierarchies without changing the classes being merged [HIT]. However, the 
language extensions and tools proposed by such research goes significantly 
beyond what we propose here, both in terms of fiexibility and complexity. 

The Fortress programming language [51 [9], like SFMJ, uses symmet- 
ric encapsulated multi-methods. However, where we incorporate them in a 
class-only context, they propose a dedicated model based on components, 
traits and objects. Also, we provide a formal semantics and proof of sound- 
ness for our scheme. 

As noted before, symmetric methods may be employed with single dis- 
patch. However, using multiple dispatch enriches the facility greatly. Multi- 
ple dispatch in the context of class-based programming languages has been 
extensively studied, both in terms of theoretical treatments [10], and as prac- 
tical extensions to mainstream languages to a.o. C++ |llj . Smalltalk |12j . 
and even ML (with added object-oriented features) [13]. Two extensions to 
Java are of particular note. 

Boyland et al. propose parasitic methods |14j . Parasitic methods may 
dynamically overload other methods. Definition of parasitic methods is con- 
strained to preserve modularity and separate compilation. The extension 
supports both covariant and contravariant specialization of methods. Some 
of the overloading strategies it supports, however, seem somewhat complex 
for programmers to confidently predict branch selection. 

MultiJava [15] is an extension of Java to support symmetric multiple dis- 
patch. Its emphasis lies on modularity and backward-compatibility. Multi- 
Java also offers open classes: classes to which methods can be added without 
changing the original class definition. MultiJava does not support symmet- 
ric methods or the definition of methods outside the class of the receiving 
argument. Open classes can only be extended by adding methods to the 
class; methods may not be moved to another class like our design allows. 

There has been significant research focusing on the modularity issues as- 
sociated with multi-methods. Millstein and Chambers jl6j propose a number 
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of different (language independent) constraints that yield different trade-offs 
between flexibility and modularity. Based on these ideas, they propose Re- 
laxed MultiJava [T7]. Finally, techniques from predicate dispatch -a gener- 
alization of type-based dispatch- have been brought to bear on the problem 
by Frost et al. [IB]. 

4 Conclusions and Further Work 

In this article, we have argued that interfaces in mainstream object-oriented 
languages, by leaking where methods are implemented, unduly restrict some 
useful forms of program evolution. We have proposed a simple scheme that 
mitigates this problem to some degree. The scheme consists of making it 
possible to define methods in the classes of any of its parameters. This means 
that a method may be moved to another of its parameter classes (but not 
any other classes) without breaking client code. To maintain object-oriented 
extensibility this implies the use of dynamic dispatch on all parameters. In 
the presence of multiple dispatch, a subclass of one of the parameter classes 
may define a method that overloads a method defined not in its superclass, 
but in another parameter class, and, for appropriate arguments, it would be 
this method that would be invoked. 

To illustrate the idea as clearly as possible, and to address any doubts 
as to whether the above scheme is sound, we have defined our proposal as 
an extension of Featherweight Java. It turns out that the extension can 
be kept very simple, and that we may limit the changes to FJ to method 
definition, invocation, and lookup. Also, soundness may be established in a 
similar fashion to FJ and does not pose significant challenges. 

Defining the scheme in terms of a core calculus has the disadvantage 
that only very basic object-oriented features are modelled. To come to a 
more interesting language, as further research, we would like to add more 
features. Some features may be added orthogonally. For example, there 
seems no indication that addition of imperative features is complicated by 
our scheme. Other features would be very easy to add, such as a null value. 
However, some features may pose a more significant challenge. For example 
adding support for abstract classes and interfaces may be difficult because 
of the presence of multiple dispatch. Abstract classes would introduce the 
coverage problem for overloaded methods. In our scheme, we were always 
guaranteed to have an implementation of the most general branch of an over- 
loaded method. With a naive integration with abstract classes this would 
not necessarily be always be the case. Interfaces would additionally incur 
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the problem of multiple inheritance: spurious branches may have to be de- 
fined to avoid ambiguity problems. However, solutions to these problems 
have been proposed in difi'erent contexts, and we would like to investigate 
how these could be applied to our setting. In similar vein, while our scheme 
is modular, it does not allow for separate compilation of classes, as we need 
global knowledge of method definitions to make sure we do not miss conflict- 
ing method branch definitions. We would like to investigate how the research 
on modular multiple dispatch may be applied to lift this requirement. 
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Computation Rules: e ^ e 



fields{C) = Cf 
(new C{v)).fi Vi 

Vi = new C{u) 
select{lookup{m, C)) = Bq m{B x) {return eo; } 

m{v) — > [t}/x]eo 
C <:D 



(L>)(new C{v)) new C{v) 



Congruence Rules: e — > e' 



ep eg 
eo-/ SQ.f 



m{v,ei,e) m{v,e[,e) 



new C{v, ei, e) — >■ new C{v, e[, e) 



eo e'^ 



(R-Field) 

(R-Invk) 
(R-Cast) 



(RC-Field) 
(RC-Invk) 
(RC-New-Arg) 
(RC-Cast) 



Figure 2: SFMJ: Reduction rules 
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Method lookup: 



lookup{m, C) = Bq m[Bx) {cq; } 



lookup{m, C) = lookupi{m, C, Ci), . . . , lookupi{m, C, Cn) 

lookupi{m, C, Object) = • 

CTjC) = class C extends D{...} 
C <: B Bq m{Bx) {return eo; } G M 

lookupi{m, C, C) = Bq m{Bx) {return eo; }, lookupi{m, C, D) 



CTjC) = class C extends D{...} 
C <: B Bo m{Bx) {return cq; } ^ M 

lookupi{m,C,C) = lookupi{m,C,D) 



Figure 3: Lookup in SFMJ 
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Expression typing: T \- t : C 



x:Cer 

(T-Var) 



rhx:C 

r h ep : Co fieldsjCp) = C f 
r h eo-fi ■■ Ci 

r h e : C 

Bq m{B x) {return e; } = select{lookup{m, C)) 

C<:Bo 

r h 7n{e) : C 

fields{C) = D f rhe:C C <: D 
r h new C{t) : C 

Fheo-.D D <:C 

r h (C)eo : C 

Theo-.D C<:D C^D 
r h {C)eo : C 

ri-eo:-D C ^: D D ^: C stupid warning 
r h (C)eo : C 



(T-Field) 



(T-Invk) 
(T-New) 
(T-UCast) 
(T-DCast) 
(T-SCast) 



Method typing: M OK in C 



X : C \- eo : Eo Eq <: Co 
3i G [l,n].C = d 

Co m{C x){return eo; } OK in C 



(T-Meth) 



Class typing: C OK 



fields{D) = D g 
K = C{Dg, C f) {super(5); this./ = /; } 
M OK in C 

class C extends D {Cf; KM} OK 
21 



Program typing: (CT, e) OK 



h e : C 

Vm G McT ■W€.llformed{overloaded{m)) 
[CT, e) OK 



(T-Prog) 



Reduction Rules 




Co ^ 

" ^ (RC-Invk-Recv) 
eo.m[e) eg.m(e) 


(RC-Invk-Arg) 

eo.m{v, Ci, e) eo.m{v, e^, e) 


Vi = new Ci{ui) 




select{lookup{m, Co)) = B m{B x) {return cq; } 
(new C{u)).m{v) [new C(n)/this, u/xJcq 


(R-Invk) 


Expression Typing 




r h eo : Co 




i?0 rn{B x) {return e; } = select{lookup{m, Cq)) 




r h e : C 




C<:So 
r h eo.m(e) : C 


(T-Invk) 


Method Typing 




this : C, X : C h eo : Eo £'0 <: Co 




C = Ci for an i G [1, n] 




Cr(C) = class C extends D {. . .} 




if select (lookup (m, D) = Dq m{D a;){return e^; } 




then C = D and Co = 


(T-Meth) 


Co m(C a;){return eo; } OK in C 



Figure 5: Aspects of FJ that Have Changed 
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Method lookup: 



lookup{m, C) = Bo m{Bx) {eo; } 



lookup{m,C) = lookupi{m,Ci) 
lookupi{m, Oh^ect) = • 



CTjC) = class C extends D{...} 
C <: B Bq m{Bx) {return cq; } G M 

lookupi{m, C) = Bq m{Bx) {return cq; } 

CT{C) = class C extends D {._. .} 
Bq m{Bx) {return eo; } M 

lookupi{m,C) = lookupi{m, D) 



Method selection: select{m) = m. 



select{m) = mi 



Figure 6: Lookup in FJ 
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